Уважаемые господа!
У меня есть контролер работающий в сети по протоколу Modbus RTU и приборы собственного производства. Подскажите как их связать?
Зарание спасибо!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
dimdi@pochta.ru

1. изучить протокол и сделать свой шлюз для своих приборов
2. взять готовый шлюз и прилепить его к своим приборам.

а вообще-то вам надо к электронщикам-эмбеддерам.
http://forum.electronix.ru/index.php?act=SF&s=&f=79
http://www.telesys.ru/teleconf.shtml

1.Что значит сделать свой шлюз и как?
2.Как готовый можна вцепить? И где его можна взять?

Может тут что-нить попадется нужное.

Посмотрел я тут пока не нашол то что нужно!
Но спасибо за HELP!!!!!!!!!!!!!!!!!!!!!

А верхнего уровня у Вас нет? (смысле диспетчеризации).

Нет

А что за сеть используют Ваши приборы?

Что вы вы подразумиваете по фразой "какую сеть"? Локальная сеть между приборами по протоколу Modbus RTU!

Приборы собственного производства тоже по модбасу работают? В таком случае спаяйте мужду собой кабели от "контроллер работающий в сети по протоколу Modbus RTU и приборы собственного производства"

Уточняю! Приборы не работают по протоколу Modbus RTU. Мне как раз нужно посадить этот протокол на эти приборы чтобы они работали с контроллером по этому протоколу. Но где его взять или как его написать я к сожалению незнаю, но очень хочу узнать!!!!!!!!!!!!!!

У меня есть описание протокола, правда в бумажном виде

Прошу прощение за мою наглость, но может можно его (бумажный вариант) как то преобразовать в электронный и скинуть на мыло (dimdi@pochta.ru)?
Буду очень Вам за это благодарен!!!!!!!!!!!!!!!!!!!!!!!!

у меня тут есть кое-что...

а вообще - любой поисковик выдаст массу ссылок на фразу modbus.

Благодарю! Но хотелось бы посмотреть пример написания всего протокола (желательно на Visual C++ или С)

На одном из сайтов нашол:
"То есть задача разделяется: сопряжение AT90S с используемым интерфейсом и написание протокола MODBUS. Если используется интерфейс RS-232, RS-422, RS-485 или подобные, то удобно использовать встроенный UART и микросхемы интерфейсов (ADM232, ADM485 и др)."
Скажите что означает "удобно использовать встроенный UART" и что это такое?

"У меня есть контролер работающий в сети по протоколу Modbus RTU и приборы собственного производства. Подскажите как их связать?"
и
"То есть задача разделяется: сопряжение AT90S с используемым интерфейсом и написание протокола MODBUS"
И это правильный ответ.
Сначала надо разобраться в сопряжении физических каналов, в контроллере с модбас скорее всего это интерфейс RS-232, который реализован на основе микросхемы UART. А у Вас чего?
Какие провода соединять будете?
Для начала хватит.

Не понял вопрос!
Но все же - кантроллер с протоколом модбас рту и рс-485 должен связыватся с приборами тоже имеющие рс-485. Но как я понимаю на приборах тоже должен сидеть протокол модбас рту (ведь они должны понимать что от них хочет контроллер с уже зазначеным выше протоколом)!

Хорошо, как я понял, в контроллере есть RS-485 и в вашем приборе есть RS-485. Если так, тогда дальше:
Теперь вторая часть задачи. Вы должны иметь таблицу переменных контроллера, проще говоря должны знать какая переменная определенного типа какой имеет адрес. Эту информацию даст только производитель контроллера.
Далее Вам надо дописать софт в Вашем приборе, который должен делать следующее (примерно):
1. Инициализировать порт
2. Посылать команды чтения, записи в порт. В этих командах должны быть адреса, типы и т.д. (вот это и описано в спецификации на модбас). Смысл следующий: Вы даете правильную команду чтения определенной переменной (которая лежит в контроллере) контроллер ее Вам выдает, вы должны ее правильно прочитать из порта. И наоборот.
3. Складывать эти данные куда-то в память для последующего использования.

Я в этом деле начинаючий и не совсем понял (и может быть я несовсем правильно поставил вопрос). Попробую еще раз: прибори о которых идет речь (их несколько) должны обединятся в сеть (и при этом быть слейвами), а контроллер мастером в этой сети и запрашивать у приборов нужную информацию для дальнейшей обработки (передача на верхний уровень). Так как контроллер имеет протокол модбас рту то и приборы должны работать по этому протоколу, но как это сделать?

Начнем с начала.
Ответьте на следующие вопросы:
1. У Вашего контроллера что есть - RS-232, RS-485 - что?
2. Вы можете программировать этот контроллер(конфигурировать) с целью указать какие переменные и из каких устройств(адресов устройств) получать?
3. Что за контроллер?
4. В ваших приборах есть RS-232, RS-485, как они могут общаться с внешним миром?
5. Вы можете программировать Ваши приборы? На основе какого микроконтроллера они сделаны?

Значит так:
1.Панельный контроллер фирмы "Промсат" SMH2010
2.Вналичии имеет два RS-485, один RS232, встроеный протокол Modbus RTU SB-2
3.Програмиравать его я могу
4.Приборы имеют RS-485 и поетому интерфейсу выдают инфармацию
5.Програмировать приборы в принцепе можна но на С. На основе Х51 совместимый.

Вам нужно переписать программу в Ваших приборах- встроить модбас- это я уже Вам говорил.
Рекомендую обратиться к специалистам, их, спецов по 51 микроконтроллерам в Москве масса.
Самому врядли получится.
Кстати по SMH2010 - в хелпе на SMLogix написано, что он может быть только слейвом.

Большще спасибо за обяснения!!!!!!!!11

Нашол в руководстве пользователяSMH2010:
"Контроллер SMH2010 С может работать в сети Modbus и
выполнять роль, как Слэйва, так и Мастера..."
"Использование контроллера в качестве «Мастера».
Для работы контроллера SMH2010 C в качестве «Мастера»
требуется создание соответствующей управляющей
программы. Подробнее сморите «Учебник» или «Хелп» по
работе с SmLogix."

"SMLogix реализует сетевые функции следующим образом. Проект, созданный на SMLogix позволяет использовать контроллер SMH 2010 только как «slave», следовательно, в сети требуется обязательное наличие мастера."
Это в хелпе.
Совет - не связывайтесь с SMH2010, попробуйте решить задачу на другом железе - дешевле выйдет.

Еще раз спасибо!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

вот еще кое-что по modbus нашлось:
ftp://ftp.eximer.net/upload/mcu/docs/modbus/

p.s. а это видели?

еще раз спасибо!!!!!!!!!!!!!

Господа, я тут тоже подумываю попробовать smh2010. Кто может что-нибудь посоветовать про него и какой вариант может быть дешевле?

Самый дешевый вариант - не использовать smh2010. По крайней мере, до тех пор, пока производитель сего чуда природы не сделает удобную среду разработки программ. С тем, что имеется сейчас можно работать только в ознакомительных целях, ибо для того, чтобы изменить что-то в программе или найти ошибку можно потратить не один день (и даже не неделю). Конечно, для программиста удобно, когда алгоритм полностью под контролем, но для инженера, который собирается работать с этими контроллерами - это виселица. А разобраться в чужой программе - вообще задача из ряда фантастики.

В принципе эта штука работает, мы уже реализовали несколько проектов, на Сигнетиксе SMH2010,
как одиночные проекты, так проекты где работают 3 контроллера в сети (один из них мастер-контроллер), подключали сторонние контроллеры и частотники, естественно не без проблем, а то что разобраться в проекте да и еще в чужом, то действительно язык программирования не самый лучший, макросы пришлось писать самим, потому что которые предлагают питерцы, не совсем хорошо сделаны.Удачи.

Только что наткнулся на эту тему и на совет посмотреть http://www.industrialnets.ru

Так вот, шлюз Anybus-Com AB7010 предназначен именно для подключения к сети Modbus RTU, в том числе и устройств с нестандартными протоколами.

Так что смотрите на сайт еще раз и внимательнее

Возмите например Wago I/O 750-816 с модулем интерфейса RS-485. Напишите ему программу для работы с Вашими устройствами, и связывайтесь с ним по ModBus'у. И реализовывать ModBus не нужно - у контроллера он встроенный.

Из этого сообщения непонятно:
1) Почему дешевле не работать?
2) Какой должная быть среда программирования, чтобы в ней можно было работать не только в ознакомительных целях
3) Чем программист отличается от инженера, и что надо инженеру?
4) Почему для нахождения ошибки требуется такой длительный срок от нескольких дней до нескольких недель?
5) "Виселица" для того кто собирается работать или для того кто работает? А с чем работать не "виселица"?

С уважением Вий

Начну с конца:
Работать не "виселица" с TAC Menta, Care (Honeywell), Easy Tools (Carel).
В принципе, больше ничего можно не объяснять - просто взять и сравнить SMLogix с вышеперечисленными инструментами.

Можно только уточнить, что программист от инженера отличается тем, что ему нужна даже не среда разработки, а инструмент, с помощью которого в полевых условия можно быстро исправить или написать с нуля программу. В SMLogix этого нет. Простейшая программа отнимет гораздо больше времени, главным образом из-за слишком мудреного программирования вывода сообщений на дисплей. Понятное дело, что для разработчика данного софта никаких проблем нет - можно сидеть и спокойно себе ваять, но для стороннего пользователя нужна простота и удобство.

Такие продукты получаются, когда программист делает софт под себя. А надо делать под других.

Сергей Русанов я давн оприсматривался к Вашему контроллеру, но после того как увидел среду программирования, решил его не покупать. Слишком долго писать почему - в кратце рискну предположить, Вы пошли тем же "ошибочным" путем, что и компания DEP в свое время - разработка собственной среды программирования, при этом являсь сами по себе отличными спецами в миросхемах. Теперь DEP программирует свои контроллеры преимущественно на С++, в среде программирования создаются "неответственные" приложения.
Мой Вам совет - купите лицензию на среду CoDeSys, Isagraf и т.п. и оставьте программирование - программистам, а сами сосредоточьтесь на проектировании новых изделий и создании прикладных библиотек.



Дешевле врят-ли. Из альтернатив - Unitronics, которые несколько глюковаты и Carel с дорогим софтом для программирования.

Немного поясню всем здесь присутствующим об SMH2010. Сергей привет тебе от СПб-Автоматики .
Итак начнем.
Уважаемый Abysmo программировать SMH очень и очень просто... А вот сложно например программировать Сименс S7-серии - попробуй на досуге. Через мои руки прошло множество контроллеров, в том числе программирующихся и CoDeSys. О коих могу сказать много хорошего и много плохого в том числе.
Вся сложность в освоении любых СВОБОДНОПРОГРАММИРУЕМЫХ контроллеров состоит в написании основных функций - на это может уйти до месяца, может и больше... Далее пользуйтесь на здоровье... Так мы, например, и поступили - теперь на ниписание программы на любую вентиляцию уходит от 3 до 6 часов, в зависимости от ее сложности. Зато раздолье в плане защит и т.д. А SMH со своей смешной стоимостью делает в итоге всех иностранных производителей дешевых контроллеров типа Арктики, Ремака и той же Синки с их куцыми алгоритмами и неполным набором защит...
Про минусы контроллеров от сегнетикса тоже могу сказать и говорил тому же Сергею до этого: их конструктор программ опасен для пользователя и не нужен для проектных отделов, так как не рассчитан на "фишки" проектироващиков... Еще странный ПИД-регулятор - он очень странный... Такого я еще не встречал, позавчера настраивали на объекте - так коэф. пропорциональности пришлось ставить 12 , ну интегральная составляющая получилась нормальной - 65 секунд. Еще там нет нормальной дифференциальной составляющей - вместо того чтобы при резком изменении рассогласования - прыгнуть вверх/вниз а потом по экспоненте уходить на интегральную составляющую - происходит резкий скачок вверх а потом снова вниз - никакой привод за этим не угонится... Но настройке ПИД поддается и на очень качающейся и шатающейся да к тому же неправильно подобранной системе приточной вентиляции нам удалось создать регулировку с точностью 0,1 градуса от уставки - результат неплохой... согласитесь... это при том что фильтрация сигнала от датчика стоит всего 3 секунды - поставить 10-15 и можно выйти на 0,05 градуса, но тогда пострадает пусковой процесс...
А автору этой ветки скорее всего не хватает терпения и квалификации, чтобы во всем разобраться... Так что рекомендую почитать инфу по контроллеру более подробно, а также немного подумать и почитать описание модбаса - там все таки все очень просто - это вам не Профибас тот же от Сименса...
Еще раз соглашусь, что предлагаемые производителем макросы не очень хороши, но ведь нужно и самим что то делать, если хотите извлекать прибыль...
И еще раз повторюсь - через мои руки прошло много контроллеров и SMH не самый худший из них и среда программирования более-менее нормальна. Не хватает только отладчика хоть самого простого и симулятора, но вместо него с успехом выступает сам контроллер...

Я за то, что бы каждый занимался своим делом. Ваш пример про ПИД регулятор только все подтверждает. К сожалению, мое время стоит дороже, чем время, потраченное на борьбу с ПИД регулятором и кривым софтом.
Обсуждение Segnetics можно на этом закончить - каждый все равно останется при своем. Кому то нравится ездить на "Мерседесе", а кому-то - раз в неделю ковыряться с масленкой в ходовой "Волги".

Извечный вопрос - нужен ли на фирме квалифицированный программист и нужно ли разбираться
с тем, что пользуешь. Насчет Siemens PCS7 - очень простая в работе система - просто рассчитана на высококвалифицированный персонал. Насчет ПИД-регуляторов- слабое место по-моему ВСЕХ контроллеров (кроме Siemens PX - т.к. "сняли со Step7"), применяемых в HVAC. Но, мне кажется,
они (хорошошие ПИД) там просто не НУЖНЫ.

PCS 7. Ха-ха... Естественно там все просто - но это для глобальных задач, причем немного упрощенных. ПЦС использует либо готовые блоки либо написанные разработчиком. А вот написать что-то серьезное на S7 - очень и очень сложно, особенно на STL (ассемблероподобный язык инструкций). А LAD и FBD, на которых так любят писать многие из здесь присутствующих - не подходит для более менее серьезных задач - доказано на опыте...
По поводу Сегнетикса - и сравнения Волг и Мерседесов - я бы таки сравнил по другому - Сегнетикс - мощный инструмент в умелых руках - то есть я бы его сравнил со спорткаром - пусть Российским, но в любом случае более маневренным чем Мерседес .
Скажу так - мне на изученние контроллера (любого) нужно не более недели... С тем же CoDeSys и контроллером от ОВЕНА 150-м я разобрался за ОДИН вечер дома... За второй вечер я просмотрел все фишки и вывел этот контроллер на диспетчеризацию через ОРС сервер. С тем же успехом за 3 часа КОНКРЕТНОЙ работы была почти полностью изучена СИНКО от Сименса... Сегнетикс осваивали где то неделю... Но там все сводилось к написанию макросов для вывода текста - это было не так то просто, но в итоге есть готовый макрос, о котором думать не надо...
ggg_ggg Фирме нужен квалифицированный инженер-программист всегда, вот только на практике таких немного... По поводу ПИД-регуляторов - они в принципе везде достаточно одинаковые... Но у всех есть огрехи... Самый лучший который я пока видел - ессно на Симатике 7, но так настроечных параметров у него около 20, но интересная формула и сама работа. А вот на 200-серии того же симатика 7 - там всего 2 параметра - рассогласование и ручной режим... Он с автонастройкой и чтобы его настроить нужно хорошо попарится...

А вот немного другой вопрос... Под соединяющие кабелечки (концентратор - устройство) все время применял стандартные RJ45 и витую пару 5-й категории... А вот так случилось, что попало мне достаточно большое количество кабелька 2 перевитых пары в экране - если его применить, ждать ли проблем? Вроде всего хватает... Соответственно - все вышесказанное касаеться Modbas

Нормально... Если они в экране конечно...
Если без экрана, то растояние меньше брать лучше и подальше ложить от источников помех

г. Fanat
Что касается CoDeSys- знаем, плавали. Изучить за один вечер - снимаю шляпу ... Я с PCS вожусь
много лет, да и то не скажу, что знаю. DESIGO построена на его базе, но только на детали ушло
7 месяцев - и то проблем "выше крыши". Вообще, за 20 лет работы программистом, у меня больше вопросов, чем ответов. Пойду учиться дальше, а то стыдно как-то....

Какая Десига то? Мой коллега на ней делал диспетчеризацию, причем что интересно изучал тоже сам... Так что если есть вопросы - обращайся... На сколько я помю - ничего там сложного нет тоже. Единственно, что мы не смогли сделать - так это с Десиги считать данные через ОРС, но как потом сказали официалы - это и невозможно, хотя сама Десига через ОРС данные считывает...
По поводу ПЦС - мне ента система совсем не нравится - она ориентирована на очень большие объекты, но из огромных кусков, которые она предоставляет очень сложно сложить аккуратный проект, как то криво получается. Мне гораздо более по душе сделать все так сказать вручную, причем на оригинальном языке STL, о котором писал ранее, хотя в Степе полно инструментов, таких как не только LAD, FBD - всем известные, но и Pascalу-подобный язык, а также SFC,CFC и еще что-то... В общем наворотов полно... Иногда они нужны, но большей частью нет...
Так как для быстродействующих систем - очень важен размер программы и добиться его уменьшения можно оптимизировав алгоритмы и написав их на STL...
Касательно CoDeSys - она по интерфесу очень напоминает STEP7, но язык инструкций на столько урезан, что операторы я запомнил - один раз взглянув на них... Ну а конфигурирование вх/вых - это вообще минутное дело...
Там есть еще приблуда для визуализации, но как я понял к ней уже нужна лицензия... Хотя как то в тестовом реживе она работает вроде - времени на ее разбор сейчас нету...
Всем огромное спасибо, общаться здесь интересно...

Если речь идет про считывание данных с контроллеров PX через ОРС (типа MBS - Cimetrics), то это и не получится по определению. В INSIGHT считать можно, но нужно хорошо знать Citect 5.5 (в 6.0 - это
проще пареной репы) и тонкости настройки I/O device-I/O Server ( с учетом INSIGHT-заморочек)
Есть простой вопрос- его направил в "личку".

PX - это гуд...
В то время как мы работали с Десигой - были только PRW и PRU контроллеры и Лона там не было вообще, а был DLC-Ring вроде бы, так что по первому вопросу не знаю - сможем ли помочь... Сейчас коллега придет - спрошу...
по второму вопросу - сложнее - как я понял речь идет о LON-IP-Router. Знаю LoyTec L_IP - бредовая вещь какая то... Разбирались мы с ним в свое время - долго не хотел работать, но вроде заработал потом... Нужно уточнить...
А вообще LON протокол как сеть не приемлю в принципе... Минусов куча, а достоинство только одно - простота... Ну для зарубежных "специалистов" это гуд, а в реальности не очень... Я лично любитель быстрого опроса... Не менее 2 секунд на переменную... К сожалению в сети LON с 1000 переменных и первоначальной скоростью в 76кбит/сек это невозможно в принципе, а роутеры только собирают информацию и передают ее через Езернет...
Есть опыт - сервак с ОРС Лоновским и 1500-переменных - загибался при времени опроса 5 секунд... Ну не успевал данные считывать... Обыдно...
Ну а самый гланый минус это наличие типов переменных - NVI и NVO. Очень "красиво" смотрятся уставка температуры... NVI - это чтобы ее изменить, а NVO - чтобы ее посмотреть... Причем любое тело с панели управления контроллера может ее изменить... В смысле NVO... А NVI при этом не изменится... Это точно справедливо для контроллеров Джонсонс... По остальным утверждать не берусь... Итак по уставкам и их отображениям колличество переменных в сеть увеличивается ровно в 2 раза... Причем не абы каких, а слово или двойное слово, а после упаковки протоколом я думаю там и на 5-10 слов раздует... Вот и считайте любители ЛОНа, а так ли он хорош на самом деле...

"Золотое правило" никто не отменял - "выигрывая в одном, проигрываешь в другом". LONTalk ничем не лучше других, математика- упрямая штука, а все протоколы сторятся по отработанным в 60-70 года
матмоделям. Просто задаются разные граничные условия. Протокол выбирается исходя из задачи -это аксиома.

А по моему нет... Просто кто-то начал в свое время работать с ЛОНом - вот и сидит на нем... Скидки и лень делают свое дело... Ну иногда заказчик обязует, но всегда есть возможность его переубедить... Это тоже проверено...

Если вас тема с упрощением инженерного труда волнует - попробуйте SMConctructor. Он объединяет идею готовых алгоритмов и FBD-программирования. В результате скорость разработки проекта вырастает в десятки раз. Лично я уверен в будущем программ такого рода, просто, чтобы пользователи их оценили надо, некоторое время и "критическая масса" реализуемых функций. Преимущество "Конструктора" в том, что он поддерживает огромное количество комбинаций, его модернизация сильно упрощается. Другими словами, те кто сейчас освоит "Конструктор" через некоторое время смогут получить преимущество в скорости разработок даже перед именитыми зарубежными брендами.

Критика "Конструктора" связана с синдромом "нового продукта" (разве новая продукция бывает 100% идеальной?). Да, нам приходится устранять мелкие недочеты, которые, увы, пропустили при тестировании. При всем этом, концептуальных ошибок в заложеных алгоритмах нет. Пройдет немного времени, добавится функций и конечные заказчики и пользователи смогут оценить, качество систем управления, построенных на SMH2010 с помощью "Конструктора".


Мы, безусловно, ценим мнение Анатолия Борисовича Колупаева (ttt). Он хороший уважаемый специалист, однако, просьба: раз уж критикуете SMH2010, то на основании фактов. А то выглядит как черный пиар. Вы ведь купили у нас образец 2 года назад (ядро очень старое), проектов на нем не реализовывали никаких, т.е. опыта работы с контроллером нет. Как можно давать такие радикальные советы? Зачем очернять собственную репутацию на страницах этого форума? Оно вам надо?

П.С. Объем продаж ТАС от этого точно не повысится.